⚠️ Potential issue | 🟠 Major | ⚡ Quick win

# First, locate the MuiTable component
fd -t f "table" -p | grep -i mui | head -20

# Search for MuiTable component in the codebase
rg "MuiTable|export.*Table" --type ts --type tsx --type js --type jsx | grep -i component | head -20

# Search for the openstack-uicore-foundation import path mentioned in the review
rg "openstack-uicore-foundation" --type ts --type tsx --type js --type jsx

# Read the email template list page to see how MuiTable is imported and used
cat -n src/pages/emails/email-template-list-page.js | head -100

# Search for MuiTable import without tsx filter
rg "MuiTable|from.*table" src/pages/emails/email-template-list-page.js

# Look for the component being used in the file
rg "const.*MuiTable|import.*MuiTable" --type js

# Read the MuiTable usage in the email template page around line 168
cat -n src/pages/emails/email-template-list-page.js | sed -n '150,180p'

# Check similar usage patterns in other files with onDelete
rg -A 3 "onDelete=" src/pages/sponsors/sponsor-list-page.js

# Look at another similar file to understand the pattern
cat -n src/pages/sponsors/sponsor-list-page.js | grep -A 30 "const handleDelete"

# Check another file to confirm the pattern
cat -n src/pages/sponsors/sponsor-forms-list-page/index.js | grep -A 2 "const handleDelete"

# Check one more for consistency
rg -B 2 -A 2 "const handleDelete.*\(.*Id\)" src/pages/ | head -30

Fix MuiTable delete callback parameter handling.

The onDelete callback receives the row identifier as a primitive value, not the full row object. With the current handler expecting row.id, the delete call will pass undefined as the template id.

-  const handleDeleteEmailTemplate = (row) => {
-    removeEmailTemplate(row.id);
+  const handleDeleteEmailTemplate = (templateId) => {
+    removeEmailTemplate(templateId);
   };

Also applies to: Line 168

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/pages/emails/email-template-list-page.js` around lines 81 - 83, The
delete handler expects a row object but the MuiTable onDelete callback passes
the row id primitive; change the handler signature from (row) to (id) and call
removeEmailTemplate(id) instead of removeEmailTemplate(row.id). Update every
place that currently reads row.id (including the other delete handler instance
that mirrors handleDeleteEmailTemplate) to accept the id primitive and forward
it to removeEmailTemplate.

The original POST path called showMessage with a callback that navigated to the new template after the user dismissed the modal:

dispatch(showMessage(success_message, () => {
  history.push(`/app/emails/templates/${payload.response.id}`);
}));

showSuccessMessage here is a toast — no callback, no navigation. edit-email-template-page.js passes saveEmailTemplate directly as onSubmit with no .then() in the component, so there is no fallback navigation either. After creating a template the user sees the toast and stays on the blank create form with no path to the new entity.

Either restore history.push in this action, or add a .then(({ response }) => history.push(/app/emails/templates/${response.id})) in the page component.

This file covers saveEmailTemplate only. Two other actions changed in this PR have no test coverage:

getEmailTemplates — the REQUEST payload now includes page and perPage for the first time (previously only order, orderDir, term). The reducer reads those fields to set currentPage and perPage state. Worth a test asserting the REQUEST_TEMPLATES action carries { page, perPage }:

describe('getEmailTemplates', () => {
  it('dispatches REQUEST_TEMPLATES with page and perPage', async () => {
    const store = mockStore({});
    store.dispatch(getEmailTemplates('foo', 2, 25));
    await flushPromises();
    const req = store.getActions().find(a => a.type === 'REQUEST_TEMPLATES');
    expect(req.payload).toMatchObject({ page: 2, perPage: 25 });
  });
});

deleteEmailTemplate — no test verifies that TEMPLATE_DELETED is dispatched with the correct templateId on a successful delete.